chore: matrix testing pre-existing k3d clusters #944
Conversation
Signed-off-by: catsby <clint@ctshryock.com>
catsby
requested review from
UncleGedd,
jeff-mccoy,
decleaver and
TristanHoladay
as code owners
Signed-off-by: catsby <clint@ctshryock.com>
Signed-off-by: catsby <clint@ctshryock.com>
Signed-off-by: catsby <clint@ctshryock.com>
Signed-off-by: catsby <clint@ctshryock.com>
Signed-off-by: catsby <clint@ctshryock.com>
Signed-off-by: catsby <clint@ctshryock.com>
Signed-off-by: catsby <clint@ctshryock.com>
| - existing-cluster: without-cluster | ||
| create-cluster: 'false' | ||
| - existing-cluster: with-cluster | ||
| create-cluster: 'true' |
There was a problem hiding this comment.
Open to suggestions on naming here, but basically wanted to convey that one matrix test operates by installing k3d and creating a cluster, while the other specifically does not create the cluster.
There was a problem hiding this comment.
Would it be clearer if this were just existing-cluster as a true/false and then pass the inverse to the action below? I'm not a big fan of the second matrix parameter here when it's really the same as the first just different name and truthy vs descriptive string.
Edit: forgot that the matrix value gets used in the job name when viewing it, so true/false would be a bit weird and unhelpful there. But maybe could still delete the second matrix param and use a string equality check below to pass true/false into the action?
There was a problem hiding this comment.
forgot that the matrix value gets used in the job name when viewing it, so true/false would be a bit weird and unhelpful there.
Maybe this depends on how it's named? In this case, the label is being used, not the value:
But maybe I'm misunderstanding what you're saying here, I'm not fully versed in GitHub Actions these days
There was a problem hiding this comment.
ah ok re-reading this I believe you're referring to existing-cluster: [with-cluster, without-cluster], I thought you were referring to the include: part.
There was a problem hiding this comment.
Added suggestions that I think would work? Would also need to do the same on the release test of course, but wanted to add for your thoughts.
catsby
changed the title
Co-authored-by: Micah Nagel <micah.nagel@defenseunicorns.com>
Co-authored-by: Micah Nagel <micah.nagel@defenseunicorns.com>
Signed-off-by: catsby <clint@ctshryock.com>
Signed-off-by: catsby <clint@ctshryock.com>
* main: chore(deps): update actions/checkout action to v4.2.0 (#943) fix: add suffix to smoke test logs (#947) chore: matrix testing pre-existing k3d clusters (#944) chore: remove nascent state tracking (#942) fix: ensure runtime bins are included in releases (#939) chore: update uds ui docs (#937) fix: update maru-runner to silence info log (#925) chore: manually bump uds-runtime to v0.4.0 (#938) chore(deps): update module github.com/prometheus/common to v0.59.1 (#877) fix(deps): update kubernetes packages to v0.31.1 (#932) fix(deps): update module github.com/defenseunicorns/maru-runner to v0.2.3 (#933) fix(deps): update module github.com/defenseunicorns/pkg/oci to v1.0.2 (#934) chore(deps): update defenseunicorns/uds-common action to v0.13.0 (#935)
Description
Cleanup some of our GitHub Actions, and run (some of?) our e2e tests in a matrix where one scenario we have k3d installed and a cluster created, and another with k3d installed and no cluster created.
Note about our
setup-golangaction: I noticed that we were usingsetup-goto install go1.21.x, however thesetup-goaction does not list the.xsyntax as supported. Furthermore ourgo.modfile says go 1.22.4, so the setup go action was setting 1.21.x, and then immediately switching to go 1.22.4 because that's what our go.mod says. The result was a long list of errors trying to use 1.22 because it was being pulled from cache but conflicted with the 1.21 we just setup.See here for example: https://github.com/defenseunicorns/uds-cli/actions/runs/11037302233/job/30657907519#step:3:102
Note about our
setup-from-previousaction: I noticed that every invocation was preceded by acheckoutaction, and the first step ofsetup-from-previouswas also a checkout.See here and here for example of trying to checkout the repo 2x in the same job
Related Issue
Fixes #940
Type of change
Checklist before merging